I'm keeping my homepage in a SVN repository; I'm using the $Date$ variable to automatically track the last modification date (though it will also change on minor modifications). For the HTML "Date" meta tag, the W3C recommends using ISO8601 date format. This is the (non-XSLT-2, so no regexp) hack I use for conversion:

<xsl:value-of select="concat(substring($string,8,4),'-',substring($string,13,2),'-',substring($string,16,2),'T',substring($string,19,8),substring($string,28,5))" />

Did I mention I hate XSLT? It's lacking so many standard functions, like date-time processing, regular expressions, exceptions, ... - granted, a lot of stuff was added for XSLT2, but it still sucks badly. Especially the syntax. Here's how to format the date according to RFC 2616, as used in the last-modified meta tag and HTTP/NNTP/SMTP headers:

<xsl:variable name="day" select="concat(substring($string,8,4),'-',substring($string,13,2),'-',substring($string,16,2))" />
<xsl:variable name="time" select="substring($string,19,8)" />
<xsl:variable name="timezone" select="substring($string,28,5)" />
<xsl:value-of select="date:day-abbreviation($day)" />
<xsl:text>, </xsl:text>
<xsl:value-of select="date:day-in-month($day)" />
<xsl:text> </xsl:text>
<xsl:value-of select="date:month-abbreviation($day)" />
<xsl:text> </xsl:text>
<xsl:value-of select="date:year($day)" />
<xsl:text> </xsl:text>
<xsl:value-of select="date:time($time)" />
<xsl:text> </xsl:text>
<xsl:value-of select="$timezone" />

Note that this does not include any error handling and is not very robust. You also need an XSLT processor with some of the ">">">http://exslt.org/dates-and-times extensions such as xsltproc. (Which unfortunately doesn't do XSLT2 yet and doesn't have a regexp extension). [Update: Joel Wreed pointed me to his libxslt plugins, a regexp and a exsl.org/dates-and-times plugin. These would help a lot, though IIRC the date-parse exsl.org spec doesn't support the date format I'd need. (So I can't just say date-format(date-parse(...),...)). Also he said that they basically are unmaintained right now. It would be nice if they could be merged into libxslt, though...]

Last night I called Ubunteros nearby Manila for the Edgy Eft (belated) release party at the Coffee Bean and Tea Leaf at Greenbelt 3. Little did I know that there will be a lot of folks coming from the just-concluded FOSS@work workshop joining in the fun, thanks to Yolynne Medina and Eric Pareja. Diane Gonzales and I got to the venue first, then followed by the FOSS@Work folks. Dominique Cimafranca, Migs Paraz, Ranulf Goss, Jopes Gallardo, and Joel Bryan Juliano were there too, and all in all we were easily the noisiest group in the coffee shop, seemingly occupying the entirety of the place. I originally planned to move the group to have dinner somewhere, but along the way everybody seemed to forgot dinner and we quite engaged in talking to everyone else. It was terrific. The 2 boxes of Edgy ,K,Ed Ubuntu CDs I brought were easily given away to everyone; we even had them exchanged and autographed (naks!) reminiscent of what Ealden and I did last February when Mark came here. As a finale, we had a group photo of everyone with their CDs; Dominique remarks that in his informal’ study, more and more women prefer Ubuntu (and I sure do think he’ll be blogging more about this soon. Needless to say, the above photo doesn’t do great justice to what happened last night; it came from my elric which I didn’t get use much as a camera since I too was happily chatting away. That said, I expect RJ Ian will be posting his photos from his brand-spanking-new Kodak camera to the Ubuntu-PH site once he gets back to Mindanao with Yolynne and company. I also think the FOSS@Work folks also have their own photosite or wiki to post more photos, which we’ll be seeing sooner. Jerome Gotangco and Ealden Esca an, the guys whom we all owe Ubuntu-PH to, were unfortunately unable to attend last night, as Jerome was off to Cebu to participate in the ICT congress there, while Ealden was quite busy at work. Hopefully they (as well as last night’s attendees!) can attend the next Release Party for 7.04 (aka Feisty Fawn,) and hopefully it will be just as fun, and be more meaningful if more Ubuntu-PH folks get involved in its development! Update: Yolynne and RJ just posted pics fresh from their arrival to home. Expect more pics later, nicely tagged too…

It seems that yet again Microsoft developers are incapable of keeping time correctly. Apparently there's a bloody stupid bug in Exchange Server which means it will get the date of the end of BST (British Summer Time) wrong this year. October is only supposed to have 4 Sundays, not 5. At least, that's the assumption their high-quality software makes. This is far from the first time that I've heard of silly bugs in Windows and Microsoft apps when it comes to handling time and date information. Still, it could be worse. At least they wouldn't try to bury this kind of insanity inside a programming language or inside an international "standard". Oh, wait...

Are there any cell phone interface design principles? (Google’s answer is inconclusive.) I would think a multi-billion dollar industry would have developed some best practices at this point, but it seems like each new phone is designed by monkeys jumping on typewriters. Maybe eventually they’ll get it right, but I’d rather not wait until infinity. A persistent flaw that has always puzzled me across nearly all models is the “shut down sound” feature. If you are shutting off your cell phone, do you really need a distinctive musical reminder? Did the designers of this feature ever consider that, in many instances, the user is shutting off the cell phone because they are in a silent theatre or a business meeting? Who are these designers, anyway? Of course you can always turn the volume down first (or probably better — just silence the phone and keep it on), but that is not going to be the first inclination for most users. I was reminded of this flaw last night at a Counterpoint Concert that was being recorded for VPR radio broadcast. After the chorus director reminded people to turn off their cell phones for the recording, a symphony of shut down sounds followed shortly thereafter. Cell phone gripes aside, the concert was great — particularly the performance of They Called Her Moses. On a related note, see this petition regarding cell phone user interfaces and software. Joel on Software also has some nice observations on this topic.

I went for a nice hike today up near Mt Hamilton with Matt and Val. We were fortunate that the rain did not start coming down until we got back to google after shopping at REI and enjoying some In-N-Out. When we finished the hike Val said that I set a good pace. Which was the same thing Ben said to me after we ran for the first time.

Other fun stuff this weekend included a BBQ at Joel & Rhoda's which included watching the horrible MST3K movie "Pod People". Friday, Jeff, Katelyn, Monkey and I went to see Shana Morrison (Van's daughter) up in Berkeley. The show was mediocre, oh well, it was good to get out.

Actually, I have no idea whether it sucks or not, because even though I signed up for the beta program months ago, I’ve yet to hear word one from Yahoo, not even a “thanks for your interest, we’ll get back to you”. In many ways, this is the inverse of what Joel Spolsky wrote about a few weeks ago, namely holding your cards too close to the vest. Now, I understand why Yahoo is being extraordinarily deliberate about rolling out such a radical UI change to the general population (after all, Yahoo Mail is used by millions of “ordinary” people), but I’m technically savvy, an early adopter, and willing to endure spotty service from time to time to get early access, not to mention that I want to give my feedback on how things can be improved for all those ordinary people. Why on earth doesn’t Yahoo want to take advantage of my offer of free labor?! So, while I have no idea whether Yahoo Mail Beta sucks or not, the very fact that I don’t sucks in itself. Ah well. I’m no longer interested in being a Yahoo customer anyway, since they’re apparently the phone company now. Speaking of not hearing word one, I haven’t heard a peep from Yahoo about that earlier post either, not even from Yahoo’s voice in the blogosphere (who also didn’t respond to email on the subject), and not even after getting a link from Doc, which no doubt got my sob story in front of many more eyeballs than would otherwise have seen it. So, it would appear my friend is SOL. I’m sure all those people who are emailing him at Yahoo will understand why he’s ignoring them. And I’m sure the years worth of data he’s accumulated at Yahoo can be easily recreated. Technorati Tags: softwareasaservice, web20, yahoo

Joel Spolsky: “Listen, I know that everybody is saying that the cool thing to do these days is Ship Early and Often, but when you ship half-baked ajax calendars that don’t do much and then get Scoble to go nuts about how great they are, well, you’re going to have a lot of people like me checking it out and realizing that, for example, no thought whatsoever has gone into printing, which is fine, it’s a 1.0 release, but you know what? I’m not going to look at 30 Boxes again — I’ve spent enough time evaluating it. G’bye. I’ve talked about this before — it’s the Marimba phenomenon — when you get premature publicity, lots of people check out your thing, and it’s not done yet, so now most of the people that tried your thing think it’s lame, and now you have two problems: your thing is lame and everybody knows it.” “Release early, release often” is a strategy that works because it allows for incremental improvement—you don’t have these “big bang” releases every few years where you try to anticipate what your users will want, because your users are telling you what they want every step of the way while the thing is coming together. That said, Joel makes some very good points, and companies following the “release early, release often” formula would do well to consider them. In short, for “release early, release often” not to backfire, its proponents need to do a better job differentiating between the users that want to actively participate in the development of a new product and the users that are simply looking to solve a problem, because that latter group is ultimately going to be disappointed if the thing isn’t fully baked.

I agree Matthew Palmer, and by extension Joel on Joel on Software that rewriting software projects from scratch is a very bad idea, which in case of FOSS can mean death of the project because people lost interest on it due to the great effort needed to reimplement things that were working before. At the same time I take what Joel says: programmers are, in their hearts, architects, and the first thing they want to do when they get to a site is to bulldoze the place flat and build something grand. Being myself a Civil Engineer I cannot agree most. The other option is patchy and result will never be so good as a well planned project, with a good design, time... and money. And this is one of the greatest things of software. With a good planning you can refactorize it, change what you want and even demolish and rewrite some parts, whithout having to throw away all the old code and start over.

To rewrite, or not to rewrite, that is the question. If there's one thing programmers seem to love doing, it's rewriting a piece of software from scratch. Which is funny, because "the industry" spends a lot of time bemoaning duplication of effort and generally touting "reusability" and "component-based software development". Joel on Software has a fairly good treatise on why rewriting software, in general, is a Bad Thing. I may not agree with him all the time, Joel is always worth a read, and I certainly can't fault his reasoning on this issue. My primary experience with rewriting software, as with most things software-related, is in the Free Software world. Although I've been involved in (or led) rewrites of proprietary software in the past, I've seen a lot more "let's rewrite it all" death-marches in FOSS. While I wouldn't characterise them universally as "failures", they don't seem to have the beneficial effect the authors were probably hoping for. What does seem to happen, in these FOSS projects, is that the developers squirrel themselves away in their backyard labs, using the latest and greatest in software engineering processes and tools, to produce... the same end result. (If you produce something totally different, it's not a rewrite, it's a new piece of software that does much the same things as the old one). When I say "the same end result", I mean exactly that -- it does the same thing, the code is still subject to coderot over time, and so on. It doesn't seem like much useful output has been produced. So why do we do it? Joel gives some good reasons (and why they're not such good reasons). Rewrites always take a very, very long time to do. It's in their nature. They're also very demoralising -- you're not really creating anything new, you're just recreating existing functionality. In the beginning, though, it's amazingly exciting -- a whole new world of bugfree code, an engineering marvel, something for the annals of software history. But several months later, as your new code is becoming cruftier by the day, and you're just duplicating functionality that already exists, you get bored. And boredom is the death knell of FOSS projects. I presume that this excitement-fading-to-boredom progression is why everyone starts rewrites, but they're often abandoned (or, at least, take a lot longer to complete than estimated). I'd make a comparison to that favourite target of unfair comparisons, marriage, but I know my wife reads my blog, so I won't. <grin>. This boredom factor is what has affected the python-appserver backed rewrite of IRM (from php3-style PHP). I took on maintenance of the existing PHP codebase over a year ago, and the rewrite had been in progress for a while at that point. IRM now has a bunch of useful new features, and there still isn't any indication of a useable tarball emerging from the rewrite. A rewrite in progress is a terrible thing. It tends to make people wary of working on the existing codebase, if it's going to be a deadend. Without something to work on, they'll tend to wander off to other projects. However, sometimes (due to existing deployments), users will work on the deadend. If the developers have been more-or-less neglecting the existing codebase while they take on their glorious rewrite, then the rest of the world is going to have been playing with and tweaking the existing code, adding their own improvements and modifications. The result of this, when the new rewrite finally releases, is that there's great wodges of third-party code that's incompatible with the rewrite, and a large chunk of your userbase says "stuff it" and sticks with what they know. This is what looks like happening in the world of SysCP. A few days ago, I found out that they're planning on doing a rewrite from the functional-spaghetti-PHP of the current version to the cult-of-MVC-PHP. This is nice, but their current estimate is of a first RC release in February. I take this estimate with a boulder of salt -- for the full collection of usual reasons (boredom, real life, overoptimism, etc). The fact that there's not a huge amount of movement on the commit log doesn't inspire confidence, either, and despite early claims of a massive development team, only one person has been committing recently. In the meantime, I'm tasked with adding a number of small features to the current SysCP codebase, which we need for work. When the rewrite comes out, it's highly unlikely that there will be a business case for rewriting my features for the new code, and it's not likely that the features we need will make it into core. So, SysCP will probably fork -- the old, featureful, crufty codebase, vs the new, shiny codebase. If there's sufficient new features to warrant an upgrade, we'll take the plunge, but what SysCP does now is very close to what we want, so it'll take a fair amount of shiny! to get us to move. This is a general issue of software development in FOSS -- if you take your eye off the ball, for any reason, someone else will probably pick it up and run with it. Your rewrite will be a completely new project, and you'll get some of the users and the fork of your old codebase will continue to live on in another guise. Let's face it, though -- your code is going to accumulate cruft. Over time, it morphs into this bletcherous pile of huge functions, multi-purpose classes, and reams and reams of bug reports. How do you deal with this cruft? Surely at some point it's easier just to throw it out and start again? Reality says no. Joel gave the key advice in the article linked above (go read it if you haven't already -- seriously), and it's strongly hinted in my article title. Don't revolt; instead, evolve your codebase. Tweak it, evolve it, move it slowly (and compatibly) towards your utopian ideal of perfect code. You won't get there, but you'll almost certainly get closer by gradual and continuous improvement than you would be going back to the start line and walking in a different direction. There's one big question that's nagging at me, though -- what happens when you want to switch languages? I'm loving Ruby on Rails at the moment, and so are several other people at work, but we've got (both personally and professionally) huge swathes of code in PHP (and other second-rate languages) that needs to be dealt with. It's a lot harder to evolve code into a different language than apply a gradual degunking. I have a number of ideas on this point, but I'd love to hear your ideas too. In a few months, I'll have a lot better idea of what works and what doesn't in massive PHP to Rails conversions, and I'm sure everyone out there in the blogosphere will hear about them in due time.

College is not the launching pad for a job. It's the launching pad for the rest of your life. High school is a mini-jail with strict standards that everyone must live up to. College is when you get to make your own choices. This is the sentiment behind this article. I agree with it on principle, but not completely on content. Computer Science in the past 7 years has gone through an evil transition - almost all of the Colleges out there shifted to a Technical style curriculum because that was what was in demand. While TAing the introductory classes here at the U of M, the most common complaint was that they weren't learning things which will be useful in the future. The classes are taught in Scheme, for reasons that I completely agree with - the students would rather have them taught in Java, because that would be useful in the market when they leave college. What were they missing? The knowledge that programming concepts are what make good programmers, not language skills. Students want cookie cutter code which solves the problems that they are given. That is why people are lambasting the teaching of Java: people aren't learning hard thinking concepts. In my opinion, college is not supposed to teach you the skills you need for your job - instead, you are there to learn your specific learning style. This will allow you to learn anything you need for your job. Most jobs which exist in the Real World™ aren't looking for people from a specific major, they're looking for experience. I also share the views that you don't need to get perfect grades - the effort required to get an A over a B+ or a B is not worth it for the slight bump in your GPA, and you will have much more fun in college. Meeting friends in college is just as important as your actual classes. The Real World ™ calls this "networking". Choosing your major in order to get a job is also such a crap shoot otherwise - you're betting that in 4 years, the market will need the skills that you learn in a major.

Via Ugo Cei I found this reading list: http://www.joelonsoftware.com/articles/FogCreekMBACurriculum.html, some of which looks to be interesting, but I'm not convinced that it's a selection where each book is a 9 or a 10. Books like the Mythical Man Month stand the test of time, and some of the books there are good ones by that measure, others look less convincing, at least judging by their contents (too focused on the 90ies, the bubble, a particular company), or some of the reviews on Amazon. Perhaps those aren't always worthwhile, but the real winners don't seem to have much flack thrown at them. I'd enjoy hearing why Joel et al. recommend them. I've read these:

• Crossing the Chasm
• Information Rules: A Strategic Guide to the Network Economy
• The Computer Consultant's Guide : Real-Life Strategies for Building a Successful Consulting Career
• The Innovator's Dilemma

in addition to Microeconomics (6th Edition) as a textbook on Economics. What are your recommendations? All things considered, though, I have a hunch that it would be better to be out trying to *do* rather than reading books about doing...

WARNING: nothing in this post has been implemented or tested, except maybe at a minimal proof-of-concept level ("it compiles!"). It's just some musings on how you can make the computer do your work for you.

I was reading a defense of Hungarian notation when I started to get a familiar notion tickling the back of my brain. The author was explaining that the original idea behind Hungarian was not to replicate type information in variable names, but rather to include some sort of usage information: one example would be giving a string value holding a value that is untrusted the name utName. While it's more reasonable than lpschwzMyVariable, this suggesion made me suspicious that the author was really hacking around suckiness in the C language.

Tagging values with usWhatever and then verifying that you never mix usBlah with Blah isn't just tedious and error-prone, it smells a lot like doing work by hand that the computer ought to do for you. It seemed to me that it ought to be possible to "tag" unsafe values at the type level and let the language's type-checker sort things out. The simple approach is of course to define something like this:

newtype Unsafe t = Unsafe t

NB: I'm using Haskell because it was the first language that sprang to mind when I thought "type system hack".

This newtype declaration lets you attach an Unsafe tag to any type. Presumably the type signatures of routines that return untrusted data (such as a hypothetical getHTMLFormValue or a routine to retrieve previously entered form values from a database, if they aren't sanitized first) should be modified; for instance, if the signature of getHTMLFormValue was

getHTMLFormValue :: HTMLForm -> String -> String

it should instead read

getHTMLFormValue :: HTMLForm -> String -> Unsafe String

To create a new Unsafe value you simply apply the Unsafe constructor to the value:

getHTMLFormValue = Unsafe (oldGetHTMLFormValue)

To unwrap Unsafes you use pattern-matching:

let (Unsafe unwrapped) = wrapped in ...

So, this sort of works, but it's unsatisfying on several levels:

• It allows the creation of types such as Unsafe Unsafe Integer and even Unsafe [Unsafe Integer]. If a value is already unsafe, how can it be "more unsafe"? And what in the world is an unsafe list, or an unsafe list of unsafe values?
  
  Unfortunately, this is probably a limitation that any scheme that relies on type-tagging will have. You can get around it by either explicitly defining each new unsafe type:
  
  

  newtype UnsafeString = Unsafe String

  
  
  This is arguably a good idea anyway, since virtually all unsafe values (in the sense the previously linked article mentiones) are likely to be strings, and as I note later, it's not clear how to "sanitize" a non-string. OTOH, placing unnecessary type restrictions feels un-Haskellish to me, and it seems likely that you can trust the programmer not to pile up Unsafes.
  
  
• This scheme makes it very tempting to strip off the unsafeness of a value and lose the fact that you did so.
  
  Since the only way to strip off unsafeness is via pattern-matching, it seems to me that it would be tempting to pattern-match away the unsafeness in function declarations:
  
  

  foo (Unsafe x) = ...

  
  
  This may be just fine, but my preference would be to forbid pattern-matching altogether (by not exporting the constructor directly to other modules; just export a normal function that constructs an Unsafe value) and instead providing two routines to remove unsafety:
  
  

  escapeData :: Unsafe t -> t
  unsafeExtractRawData :: Unsafe t -> t

  
  
  The first routine encodes the data into a "safe" form, while the second simply fetches the wrapped value:
  
  

  unsafeExtractRawData (Unsafe x) = x
  
  foo x = doSomeStuffWith (unsafeExtractRawData x)

  
  
  The rationale here is twofold: first, by giving the dangerous extraction routine a scary and hard-to-type name, you remind yourself to think twice before invoking it (cf unsafePerformIO); second, you can easily audit all the locations where the unsafety is "stripped away" with a textual search.
  
  There are some issues involving the safe encoding -- you probably ought to make a typeclass of things that can be safely encoded from an Unsafe value; not too hard and this entry is already too long.
  
  
• The final issue involves manipulation of Unsafe values. So far you can pack and unpack Unsafes; however, this seems like it would get a bit annoying if you had to do any significant operations on them. For instance, searching in an unsafe string for a substring seems like it would be a pain and a bit error-prone (since you'd have to remember to wrap the string back up in an Unsafe). You might think that ideally, all normal String operations should work directly on an Unsafe String or pairs of Unsafe Strings -- you just shouldn't be able to convert between the two.
  
  Unfortunately, I can't see any way of doing everything that you'd want to here. For some types you can. For instance, the following definitions let you compare values wrapped in Unsafe in the usual way:
  
  

  instance (Eq t) => Eq (Unsafe t) where
      (==) (Unsafe v1) (Unsafe v2)   = v1 == v2
      (/=) (Unsafe v1) (Unsafe v2)   = v1 /= v2

  
  
  This admits (Unsafe t) to the Eq class, and looks reasonable enough (assuming that it's safe to compare unsafe values, of course). However, for probably the most important Unsafe values -- Unsafe Strings -- I can't see how to do this. The problem is that String is not a typeclass, it's a synonym for [Char], a list of characters. The important string operations are either defined directly on the String type, or generically on [t]; i.e., "a list of anything". Because there is no typeclass, you simply can't overload these operations to apply to unsafe strings as well as regular strings.
  
  One way around this is to provide an "unwrapping combinator":
  
  

  liftUnsafe :: (t -> t) -> Unsafe t -> Unsafe t
  liftUnsafe f (Unsafe v) = Unsafe (f v)

  
  
  This would automatically convert string operations to unsafe-string operations; not ideal, but reasonable enough. Operators are still a little annoying, but you can mangle their names:
  
  

  (++u) :: Unsafe [t] -> Unsafe [t] -> Unsafe [t]
  (++u) = liftUnsafe (++)

  
  
  So you have to use ++u instead of ++ to concatenate unsafe lists; not too bad.
  

While it may not be perfect -- it only makes sure that you don't accidentally violate safety, and doesn't stop you from deliberately doing something dumb -- this approach feels a lot safer to me than ad-hoc mangling of variable names. I used Haskell because you can do type hacks fairly easily in it, but I don't see why you couldn't play a similar game (albeit much less conveniently) in C++, or even in a dynamic language like Python. Of course, Python would give you runtime errors about safety violations instead of static ones, but that still beats getting runtime security holes.

I would add as a hypothesis that it should be possible to express just about any variable-name-mangling technique whose goal is to "make wrong code look wrong" in the type system, provided your type system doesn't suck; and that doing so is preferable to doing it manually, since it means that a lot of repetitive error-checking can be handled by the computer. And since the computer is better than you are at verifying formal invariants, forcing it to handle them whenever possible is always a good idea.

This week's installment of Cringely's column has a slightly different take on the recurring theme of implication of the retirement of the Baby Boomers cohort:

In the U.S. the Baby Boom generation includes anyone born from 1946-64, which means everyone 41-59 years old. Those ages generally cover the top technical management positions in most companies and universities and they are starting to retire. But as anyone who reads magazines knows, this generation of upcoming retirees acts younger and healthier than the generations that preceded it and they plan to have very active older years. At the urging of reader Joel Franusic, I've been thinking of what implications this has for Open Source software. The implications are huge. Imagine 100,000 engineers and programmers leaving the U.S. work force every year for the next 18 years, because that's what is going to happen. Some of those people will find other careers, but most of them will be motivated less by money than they were earlier in their lives. Most of them will want to remain active. And once a nerd always a nerd, so I think many of them will gravitate to Open Source.

Planets are a fairly common method to aggregate blogs. They are especially pervasive in the FOSS world, with planets for Debian, Gnome, KDE, and many others. I find planets as a useful resource for a community to give a single place for the communication and to check for updates. The usual method of communication in blogs is a reply in a post, the planet makes the replies come in the same page for the reader with little context loss. For this reason I'm also fond of setting up planets myself for those communities that lack them, and so I setup planets for FOSS-IL for Israeli blogs about FOSS issues (mostly in Hebrew), Planet (former) Advogato for former Advogato bloggers and the latest one is Planet MicroISV for MicroISVs. I was asked to provide some (tutorial help something) on setting up a planet, and this post is the answer to that request.

---

The PlanetPlanet program is a very common RSS feed aggregator, it works with most feeds and is fairly tolerant to non-standard-conforming feeds. It is also relatively low maintenance, which is why I chose it for my aggregators. Prerequisites The first thing you'll need is to make sure you have Python 2.2 or better installed. If you're on a sane OS, you can just do apt-get install python2.3 otherwise you are left to fend for yourself. For the Windows folks there is ActivePython. Another would be prerequisite is GNU Arch or GNU Arch or Bazaar, two implementations for the Distributed Revision Control algorithm which was pioneered in GNU Arch. Bazaar would be more user friendly, but both IMNSHO are horrendous user-interface wise. Which is why I provide a snapshot of the latest revision for your benefit. Install Installation would be fairly simple, just unpack the tar.gz and it's installed, nothing else needs to be done, except configuring it. The snapshot I provided is just a raw dump of the arch repository, it is useful as is since you can update the installation as needed by just updating and merging with Arch/Bazaar. This will not be covered here. Too much of a trouble for now, and the PlanetPlanet development is at the pace of a snail carrying an elephant, don't expect updates in the near future. Configure I assume you have in mind the list of blogs you want to put on the planet. It need not be comprehensive, a few blogs to start would be good enough. It's trivial to add more as you go. In the planet directory you should copy the examples directory to a new one, say myplanet, copy the output directory to myplanet-output and edit the myplanet/config.ini file. At the minimum you should change the following variables:

• name – The name of your planet
• link – The URL where you planet will live, used inside the feeds the planet exports
• owner_name and owner_email – obvious isn't it?
• output_dir – that should be myplanet-output according to the instructions above
• template_files – change and replace examples with myplanet

The next stage would be to replace the existing blog listed in the config.ini file with your own list. The example is there and is trivial to follow, the entry for a blog looks like:

[http://baruch.ev-en.org/blog/index.rss2]
name = Baruch Even

Where the feed URL is in square brackets and the name of the blog is the name. There are various games that are possible with the templates but we'll ignore them for now and let you learn them from the examples provided by the authors. The next stage is just to run the planet on the new files, we will use the defaults for the rest.

python planet.py myplanet/config.ini

The planet will work for a while, churn out various uninteresting messages and generate the files we asked it for in the myplanet-output. You can now inspect the files in the output directory, load them in a browser and enjoy. Tweaks So you haven't left yet? Want some more info? One obvious question is now that we have the files, how do we serve them to the world so everyone can enjoy our creation? First, you should ask yourself if the world really cares... you do, ah?! OK. If the world cares enough it will find a way to show you how to do it. Since it depends on your OS, web server and various configurations, I can't help you on this. This is left as an exercise to the reader. The configuration in config.ini should be fairly obvious and is well commented. The look of the site depends on two factors, the HTML that is generated, which is a clean HTML version 4.01 and has all formatting controlled by the CSS file which was kindly provided in the outputs directory. The templating code is very simple, it has two operations, TMPL_LOOP and TMPL_VAR. TMPL_LOOP will loop over a variable, usually the Channels variable. And the TMPL_VAR operator will emit that variable, there are the global vars and the loop vars. The best way to figure it out is to use the existing templates as a building block, they are fairly easy to understand. Enjoy your new Planet!